EMR systems support the creation, viewing and editing of medical records. The EMR system may or may not have interoperability with other software or hardware systems. There is a general consensus that EMR systems that interoperate are needed in modern medical practices. Physicians really don’t want to shuffle papers around anymore than normal people in their general lives. And even though there are cited barriers to adoption in hospitals that include physician’s resistance, they know all too well that electronic methods of maintain patient information is here, needed, and improves overall the quality of patient care. However, the burden to make the EMR experience an enjoyable one falls squarely on the shoulders of the EMR vendor and the instrument manufacturer. The physician, who in this case is the software consumer, doesn’t care why it doesn’t work properly, or why it is difficult to use. He only sees it as a tool, much like Microsoft Word or Adobe Photoshop. It is installed to perform a job, make some effort easier, and it needs to perform flawlessly.
NAVIS is a Japanese based ophthalmology company that builds medical instruments that have limited communication capabilities with the EMR based systems in hospitals. We built a proof of concept system to educate them on the need for such a communications system and how to guide them through the process of incorporating EMR capabilities in their medical instruments
The EMR Middleware acts as a proxy between the hosptal EMR systems that are HL7 compliant in electronic communications and the NIDEK instruments, allowing for basic patient metadata exchange such as during the process of patient registration.
The project objectives may be broadly divided into three categories. The first is the type and method of data interchange between NAVIS and the EMR system. The second is the architectural implementation of the controlling process. The third is to work directly with each vendor and implement its preferred method of data communication.
To achieve these goal, a middleware solution was recommended as a proof of concept. The middleware is an application level product that communicates with both NAVIS and the EMR systems. It is responsible for making the intelligent decisions on what instruments to connect to (via NAVIS) and what EMR systems to communicate with. All data (patient demographic metadata as well as images) are transformed and marshalled by the middleware application.
Patient demographics stored on either system – NAVIS or EMR – must be interchangeable under manual or automatic control. For this proof of concept, the only direction that is implemented is the interchange of patient demographics from the EMR system to NAVIS.
Patient images are handled a bit differently. Images are normally stored on the NAVIS side because NAVIS can act as a PACS (Picture Archiving System). Therefore, the EMR system will request an image when it wants to display something associated with a patient demographic record. For this proof of concept, and depending on the vendor chosen, the images are either sent unsolicited from NAVIS to the EMR system (i.e., NextGen’s requirement) or a solicited request is made from the EMR system to NAVIS for an image (i.e., MDoffice’s requirement).
One of the technological constraints is to minimize changes made directly to either the EMR systems or to NAVIS. This will mitigate problems with burdening the technical staff at each EMR company by shifting the responsibility of the project development directly to NIDEK. As long as the EMR company maintains its external communications interface, data application as controlled by the product of this project development should not be adversely affected. Likewise, NAVIS does not have to be directly altered either in order to implement the goals of this project. NAVIS will only be modified to import and export XML files into certain folders that are being monitored.